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[57] ABSTRACT 

Managing electronic mail messages in a client-server envi- 
ronment. A database, stored at the client, maintains a central 
archive of message-related information in connection with 
messages located on the server to support current and future 
message communication operations between the client and 
the server. Message-related information is retrieved from the 
server. Based on the message-related information, a deter- 
mination is made as to whether the message has been 
downloaded from the server to the local message store 
located at the client. In response to determining that the 
message has not been downloaded, the message is down- 
loaded from the server to the local message store. Data fields 
in the client-based database are populated with the message- 
related information, and indications are provided in the 
client-based database that the message is present on the 
server and that the message has been downloaded. During 
subsequent client-server sessions, the database is then con- 
sulted for managing, the messages. The database also sup- 
ports efiBcient management of messages having multiple 
message parts i.e., message re-assembly. 
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SYSTEM AND METHOD FOR MANAGING between his or her computers. P0P3 does not have as much 

ELECTRONIC MAIL MESSAGES USING A flexibiHty as IMAP. SpecificaUy, P0P3 typicaUy requires the 

CLIENT-BASED DATABASE deletion of messages from the server after downloading 

these messages to a client. So, the user is unable to maintain 

TECHNICAL FIELD 5 messages on the server if the user so desires. In addition. 

The present invention relates to communication and stor- electronic message programs implementing the P0P3 and 

age of electronic mail messages, and more particularly IMAP protocols typicaUy contain inefficient code requiring 

relates to a system for managing electronic mail messages commands, such as LIST and P0P3 STAT, to be sent for 

using a client-based database. messages already downloaded m a local message store at a 

10 chent. 

BACKGROUND OF THE INVENTION in prior systems, multiple part messages are assembled in 
Electronic mail (e-maU) is one of the most commonly response to scanning the local message store on the client to 
used applications for distributed computer networks. The information required to combine message parts. To 
benefits of e-mail applications are obvious. Users can assemble a message comprising multiple message parts, 
quickly communicate with one another. If a person isn't P^^^^ message systems have examined contents of a local 
available to pick up a message immediately, the message is store to locate message parts. These prior message systems 
stored until that person can review the stored message at a assemble the complete message based on the identified 
later time, E-maU messages also provide a quick and easy message parts. Typically, these message parts are identified 
way to package information such as sales reports, graphics. searching the TO:/FROM: fields of messages and a 
and other data for transfer to another user by simply attach- ^° Message Part Number (message 2 of 5) to locate the 
ing the information to the message. These days, business available sections of a particular message. Searching the 
users increasingly rely on e-mail messages to share ideas, local message store, however, is at best an inefficient pro- 
transmit documents, schedule meetings, and perform a mul- cessmg operation because selected fields of all messages m 
titude of other everyday tasks. message store must be reviewed to locate all available 
Tliese tasks may be accomplished by a variety of software P^*^ ^! ^l^^"!' Although the search of the local 
programs. For example, e-mail programs facilitate the trans- message store is focused upon a Imaited set of required 
mission of messages between users. Messaging-enabled information all messages m the local message store must be 
scheduhng programs allow users to request and schedule searchmg operation, 
meetings and appointments via electronic messages. Com- Therefore, there is a need for a system that optimizes 
puter programs known as desktop information managers communication with electronic message servers. There is 
attempt to coordinate the growing stream of electronic also a need for a single mechanism for managing messages 
communications by incorporating e-mail, a calendar, task ^ a local message store located at a client. In addition, there 
management, contact management, notes, and journal fea- is a need for a system that efficiently obtains electronic 
tures into a single application program. message-related information from a server. There is a further 
The increased reliance on electronic messaging has ^ ^y^tem that reassembles messages without the 
resulted in a great increase in the number of electronic ^^^^ ^^r reviewmg each message in a local message store, 
messages a user sends and receives daily. Users who send SUMMARY OF THE INVENTION 
and receive a large number of e-mau messages would like an 

eflfective way to process their e-mail without spending a lot 4Q The present invention satisfies the above-described needs 
of time sorting through their in-box, deleting, filing, by providing a system for managing messages in a client- 
forwarding, and responding to their messages. Hence, a server environment. The present invention efficiently man- 
major problem with e-mail is that a user, can become ages messages and optimizes communication between a 
inundated with messages without an efficient and effective client and a server by using a database, stored at the client, 
means to manage them. 45 to maintain a central archive of message-related information 
Specifically, mail boxes require management to dispose of in connection with messages located on the server to support 
messages or to archive those that might be required later. current and future message communication operations 
Prior electronic message systems have managed message between the client and the server. 

operations by obtaining required message-related informa- Generally described, the present invention operates in a 
lion from the message server or by scanning messages 50 distributed computer environment, which includes a server 
maintained in the local message store at the client. These and a client including a local message store and a client- 
systems typically contain inefficient code in the messaging based database. ITie present invention provides a method for 
protocol implementation, which results in unnecessary managing electronic mail messages based on message- 
retrieval of information from the server. In addition, these related information stored in a client-based database. During 
systems do not have an efficient means for downloading 55 a client-server session, the message-related information cor- 
information and deleting unnecessary information. responding to the message is retrieved from the server. 

For example, the Internet Message Access Protocol Based on the message-related information, a determination 

(IMAP) and version 3.0 of the Post Office Protocol (P0P3) is made as to whether the message has been downloaded 

are messaging protocols that supports e-mail messages. from the server to the local message store located at the 

IMAP defines a method of accessing electronic mail or 60 cfient. In response to determining that the message has not 

bulletin board messages that are kept in a message store on been downloaded, the message is downloaded from the 

a remote mail server. IMAP permits an e-mail chent program server to the local message store located at the client. In 

to access remote message stores as if they were local. addition, data fields in the chent-based database are popu- 

Messages stored on an IMAP server can be easily manipu- lated with the message-related information, and indications 

lated by a user who uses multiple computers (e.g., a work- 65 are provided in the database that the message is present on 

station at the office and a notebook on the road) without the server and that the message has been downloaded from 

requiring the user to transfer messages or files back and forth the server to the local message store. The foregoing steps are 
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then repeated for each remaining message on the server. corresponding message entry in the database to remove the 

During subsequent client-server sessions, the database is selected message. For example, a "delete" flag can be set to 

then consulted for managing the messages. indicate that the selected message is to be removed. If a 

Typically, the step of downloading the message from the determination is made that the client is in the "leave on 

server to the client-based local message store can include 5 server- mode, another determmation is made as to whether 

, , . . , • . • i_ L . r at tmie expiration has been set for removmg the selected 

determming whether a size restriction has been set for j'^ . j « ■ *u . 4- • «■ 

, , . . , message. In response to determmme that a time expiration 

downloadmg the message If there is a size restriction, ^^^^ ^j^^^^ /^^^^ 

another determination is made as to whether a message size ^^termination is made as to whether the time has expired for 
for the message is greater than a predetermmed size limit In ^^j^^^^^ ^ Generally, to determine whether the 
response to determimng that either 1) a size restnction has 30 ^.^^ ^ ^ ^ ^ ^^^^ ^.^^ 
not been set for downloadmg the message or 2) the message ^ ^ compared to a preset period of lime aUowed for 
size for the message is not greater than the predetermmed corresponding message entry to remain in the client- 
size limn the message may then be downloaded from the ^^^^^^ ,^ determining that the time has 
server to the local message store. ^^^^ 3^,^^^^^ message, an indication is provided 
In addition in response to determimng that the message t^ie corresponding message entry in the database to 
has been downloaded from the server to the local message remove the selected message. Finally, the corresponding 
store, the message-related information corresponding to the message entry for the selected message is removed from the 
message may be identified in the client-based database and client-based database and the selected message is removed 
an indication is generally provided in that database that the from the server. 

message is present on the server. In another aspect, the present invention provides a method 
The message-related information generally includes a for assembling a message at a client, where the message has 
unique identifier for identifying the message and a session multiple message parts in a local message store located at the 
identifier for indicating the order in which the message is client. In connection with this aspect of the present 
downloaded from the server to the client. The message- invention, a corresponding message entry for each of the 
related information may also include a message size and a message parts is stored in a client-based database. Each 
date and time for the message. corresponding message entry includes a message group 
For each entry in the client-based database, the data fields identifier to identify each part of the message, a message part 
Can include a unique identification field for storing the number to identify the order of the message parts, and a total 
unique identifier, a session identification field for storing the 3Q parts number to indicate the number of parts in the message, 
session identifiers a message size field for storing the Each message entry having the same message group iden- 
message size, and a date and time field for storing the date tifier is identified in the database. The message parts having 
and time. The message-related information obtained from the same message group identifier are selected from the local 
the server can be placed in the respective data fields. message store based on the identified m,essage entries in the 
In response to populating the unique identifier and the 35 database. The message parts can then be assembled at the 
session identifier in their appropriate data fields in the client in order based on the message part number for each of 
client-based database, an "on server" flag can be set to a true the corresponding message entries in the database, 
state in the database to indicate that the message is on the Advantageously, the present invention provides a system 
server. In addition, in response to downloading the message that optimizes communication with electronic message serv- 
from the server to the local message store, a "download" flag 40 ers by using a client-database to maintain a central archive 
can be set in the database to indicate that the message has of message-related information. The present invention pro- 
been downloaded. Before each subsequent client-server vides a single mechanism for managing messages on a 
session, the session identifiers are usually cleared and the client's local message store by accessing archived informa- 
"on server" flag is generally changed from the true stale to tion in the client-based database during typical message 
an unknown slate, where the unknown state indicates that 45 communications operations. In addition, the present inven- 
the presence of the message on the server is unknown. tion efficiently reassembles messages without the need for 
Finally, during each subsequent client-server session the "on reviewing each message in a local message store by includ- 
server" flag can be changed from the unknown state to a ing in the database data fields corresponding to selected 
false slate when the message associated with the message- fields of a MIME-compalible message to support the assem- 
related information is not present on the server. As a result, 50 bly of message parts. 

an indication is provided in the client-based database to These and other objects, features, and advantages of the 

delete the message, and the message-related information for present invention may be more clearly understood and 

the message is removed from the database after each sub- appreciated from a review of the following detailed descrip- 

sequent client-server session is discontinued. tion of the disclosed embodiments and by reference to the 

In another aspect, the present invention provides a method 55 appended drawings and claims, 

for removing from the client-based database message entries BRIEF DESCRIPTION OF THE DRAWINGS 
for electronic mail messages based on message-related 

information stored in the database. The client-based data- 1 a block diagram of a cUent-server operating 

base comprises at least one message entry containing environment for an exemplary embodiment of the present 

message-related information corresponding to one of the 60 invention. 

selected messages. A determination is made as to whether FIG. 2 is a block diagram of an exemplary client system 

the client is in a "leave on server** mode, where the "leave for implementing the present invention, 

on server" mode indicates that the selected message remains FIG. 3 is a block diagram illustrating inter-operation of a 

on the server after the selected message has been down- client and server in accordance with an exemplary embodi- 

loaded from the server to the local message store located at 65 ment of the present invention. 

the clienl. If a determination is made that the client is not in FIGS. 4a, 4/?, 4c, 4d, 4e, 4/, 4g, 4A, 4/, 4;, and 4k, 

the "leave on server" mode, an indication is provided in the collectively referred to as FIGS. 4a~4ky are diagrams illus- 
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trating a message manager database for archiving messages other computer system configurations, including hand-held 

in accordance with an exemplary embodiment of the present devices, multiprocessor systems, microprocessor-based or 

invention. programmable consumer electronics, minicomputers, main- 

FIGS. 5a, 5b, and 5c are flow diagrams illustrating an frame computers, and the like, 
exemplary process for an initial download operation utiliz- 5 xhe invention may also be practiced in distributed com- 
ing a database in accordance with an exemplary embodiment puting environments where tasks are performed by remote 
of the present invention. processing devices that are linked through a communica- 

FIGS. 6a and 6b are flow diagrams Ulustrating an exem- tio°s network. In a distributed computing environment, 

plary process of populating data fields within a database. program modules may be located in both local and remote 

HGS. 7a, 7b, 7c, and Id are flow diagrams illustrating an '° °^*^°^°^y storage devices. Execution of the program modules 

exemplary process of downloading and deleting information ^j^^ ^^^"y a stand-alone manner or remotely m a 

subsequent to an initial download operation in accordance chent/server manner. Examples of such distribut^l comput- 

-.u ™ 1 . ^«u«^ «f -^.r^^fi^r. ing environments include local area networks of an office, 

with an exemplary embodiment or the present invention. * . . , , , . , 

^ ^ . . . , enterprise- wide computer networks, and the Internet. 

FIG. 8 is a flow diagram illustrating an exemplary process 15 . , , . , . 1 , ^ . 

of reassembling a message having multiple parts in accor- '^e Internet which is a global web of mterconnected 

dance with an exemplary embodiment of the present inven- computers and ojmputer networks, mtegrates local area 

j-Qjj networks (LANS) located in various entities, such as 

businesses, libraries, federal agencies, institutes of learning, 

DETAILED DESCRIPTION research organizations into a single communication 

network. The Internet uses a common communication pro- 

The present invention provides a system for managing tocol suite, known as a Transmission Control Protocol/ 
messages communicated within a client-server architecture, Internet Protocol (TCP/IP), which was specifically designed 
such as a distributed computing environment represented by for the interconnection of different computer systems. Inter- 
a client and a server. In an exemplary embodiment, the nal and external networks are linked by routers that route 
invention is incorporated into the "MICROSOFT OUT- 25 j^j^ packets from a sending network to another router or a 
LOOK '98" application program, which is produced and receiving network. Gateways handle data transfer and con- 
distributed by Microsoft Corporation of Redmond, Wash- version of messages from a sending network to the protocols 
ington. The "MICROSOFT OUTLOOK '98" application used by a receiving network. Typically, gateways refer to 
program manages e-mail calendars, contacts, tasks and to-do devices that translate between applications. For example, 
lists, and documents or files on a hard drive. The present e-mail gateways translate messages from one vendor's mes- 
invention, namely a message manager program module saging program to another vendor's messaging program so 
("message manager"), uses a database, stored at the client, that users with different e-mail programs can share messages 
to maintain a central archive of message -related information over a network. 

to support current and future message communication opera- -^h^ internet uses a message standard, known as a Simple 

tions between the client and the server. Transfer Protocol (SMTP), which works in conjunction 

In the present invention, communications with a message with a user's e-mail program and defines the control mes- 

server are facilitated by accessing a client-based database sages used by two computers to exchange e-mail messages, 

representing a central archive of message -related informa- Such controls include verification of proper connection, 

tion. The present invention accesses archived information in ^ identification of sender, negotiation of transmission 

the client-based database during typical message communi- parameters, and message transmission. SMTP is responsible 

cations operations, such as message download and delete for l) sending mail created by a local user to another 

operations. The client-based database is also used to support computer and 2) receiving mail from other computers on the 

eflScient management of messages having multiple message network and transferring it to the local user's e-mail pro- 

parts, i.e., message re-assembly. The database of the present gram. 

invention includes data fields corresponding to selected Typically, the computers connected to a wide area net- 
fields of a MIME-compatible message to support the assem- ^^^^ ^^^^^ ^^^^^^^^ identified as either servers or 
bly of message parts. clients. A server is at computer that stores files that are 

Referring now to the drawings, in which like numerals available to the other computers connected to the network, 

represent like elements throughout the several figures, For example, an e-mail server manages message traffic and 

aspects of the present invention and an exemplary operating mail boxes for users, in addition to translation facilities or 

environment will be described. gateways that allow message exchange between different 

types of e-mail programs. A client is a computer connected 

EXEMPLARY OPERAHNG ENVIRONMENT to the network that accesses shared resources provided by a 

The following discussion is intended to provide a general 55 server. To obtain information from a server, a client makes 
description of a suitable computing, environment in which a request for a file or information located on the server using 
the invention may be implemented. While the invention will a specified protocol. Upon reception of a properly formatted 
be described in the general context of an application pro- request, the server downloads the file or information to a 
gram that runs on an operating system in conjunction with local message store located at the client, 
a personal computer and in cormection with a server, those 60 FIG. 1 illustrates a typical client-server environment 10 in 
skilled in the art will recognize that the invention also may which the present invention operates. A computer system or 
be implemented in combination with other program mod- client 1, such as a conventional personal computer or any 
ules. Generally, program modules include routines, operat- device operable to communicate over a network, is con- 
ing systems, application programs, components, data nected to an Internet server computer 3 ("server"). The 
structures, etc. that perform particular tasks or implement 65 server 3 is generally provided by an Internet service provider 
particular abstract data types. Moreover, those skilled in the . (ISP), which provides Internet access. The server 3 is 
art will appreciate that the invention may be practiced with connected to a distributed computer network 5, such as the 
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Internet, and enables the client 1 to communicate via the monitor, personal computers typically include other periph- 

distributed computer network 5. eral output devices (not shown), such as speakers or printers. 

The client 1 communicates via the combination of the x^e client 20 operates typically in a networked environ- 

server 3 and the distributed computer network 5 to a server uj^m u^ing logical connections to one or more remote 
7, such as a communication or an e-mail server. In an 5 computers, such as a remote computer 49. The remote 

exernplary embodiment, servers 3 and 7 support e-mail computer 49 may be an e-mail server (which includes one or 

services, contam a message store for holding messages until ^^^^ ^^^^^^^ ^ described above in connection with 

delivery, and oontam a translation acUity or gateway for ^ ^^^^^^^ ^^^.^^ .^^j^^^^ ^^^^ ^^^^^^^ 

allowing users havmg different e-mail programs to exchange / , - * 1 j j 

•11^ _ . . , , • . 1 * 1 n J a router, a peer device or other common network node, and 

fK''T!'ff° T^iT '° lypical'y i»<=l"des many or all of the elements described 

enables the chent 1 to communicate with the chents lla, •'f,, \ , i*u u 1 

i*in relative to the client 20, although only a memory storage 

116 and Uc via the interna network 9 ^^^.^ ^ ^^^^ jj,^^,^^^^^ ^q'^. Tlie logical con- 

ITie chents 11«, 116, and 11c are not only able to respond ^ j^j^j j include a local area network 

to a communication from the clieiit 1. but are ako able to (^AN) 51 and a wide area network (WAN) 52. Such 

!?l'i'''^'^?'"""^'T.?''''''^''''°'u 1' networking environments are commonplace in offices, 

116, and 11c can send information via the mternal network enterprise-wide computer networks, intranets and the Inter- 
9 to the server 7. The server 7, in turn, forwards the 

information to the client 1 via the distributed computer ',, . . , .vi i • • i- 

network 5. TTie information is retrieved by the server 3 and , ^hen used .n a LAN networking environment the chent 

can be forwarded to the client 1, when requested by the <=?°n««'«d 'o the LAN 51 through a network interface 

^^^^j 2 J ^ 52 When used in a WAN networking environment, the 

„ , ^ 1 . r • 1 client 20 typically includes a modem 54 or other means for 

With reference to FIG. 2, an exemplary system tor imple- * l- • *u i^/axtc--^ u 

. . . , J .-1 1 establishing communications over the WAN 52, such as the 

mentmg the mvention includes a conventional personal , . , ™f , ca i.- u • * / * i 

. . , ^ • .^n. Internet. The modem 54, which may be internal or external, 

computer 20, which serves as a chent. The client 20 may * j * *u * u -^i • *u • i * • * r 

*^ , 11 r *u 1 * -1 ii Ml is connected to the system bus 23 via the senal port interface 

represent any or aU or the clients lla, IIZ?, and 11c illus- 25>i^i - * 

J- i-T/-.^ 1- .-^n- 1 J • 46. In a networked envu-onment, program modules depicted 

trated m FIG. 1. The client 20 mcludes a processing umt 21, i . v * m /• tL c l * j 

J u .t- . 1 .L relative to the client 20. or portions thereof, may be stored 

a system memory 22, and a system bus 23 that couples the ... . * i • i* nu i 

\ ^ . * r™ in the remote memory storage device. It will be appreciated 

system memory to the processmg unit 21, The system ,u wu *, i u i j *u 

• 1 J J 1 J that the network connections shown are exemplary and other 

memory 22 mcludes read only memory (ROM) 24 and r * ui- • *• i* i u *, .u 

. ^ A* A A L • • . . means of establishing a communications hnk between the 

random access memory (RAM) 25. A basic input/output 30 ^xx^x% ma be u^d 

system 26 (BIOS), containing the basic routines that help to compu ers may e use 

transfer information between elements within the cUent 20, With contmmng reference to FIGS. 1 and 2, HG. 3 is a 
such as durinL, START-up, is stored in ROM 24, The client diagram lUustratmg inter-operation of a client and server m 
20 further includes a hard disk drive 27, a magnetic disk accordance with an exemplary embodmient of the present 
drive 28. e.g., to read from or write to a removable disk 29, 35 invention. This exemplary embodiment is embodied in the 
and an optical disk drive 30, e.g., for reading a CD-ROM "MICROSOFT OUTLOOK '98" application program, 
disk 31 or to read from or write to other optical media. The ^^ich is published by Microsoft Corporation of Redmond, 
hard disk drive 27, magnetic disk drive 28, and optical disk Washington. The program helps users communicate through 
drive 30 are connected to the system bus 23 by at hard disk ^-"^^i^' P^^^^ support and group scheduhng capabiUties, and 
drive interface 32, a magnetic disk drive imerface 33, and an 40 ^"^^^ ^^^^ ^« ^^^^'^ ^^^^ information using a consis- 
optical drive interface 34, respectively. The drives and their ^ent interface. The "MICROSOFT OUTLOOK '98" pro- 
associated computer-readable media provide nonvolatile S^^m supports an exemplary program module, namely a 
storage for the client 20. Although the description of "i^^sage manager program module 37, for managing mes- 
computer-readable media above refers to a hard disk, a ^ages. The "MICROSOFT OUTLOOK *98" program also 
removable magnetic disk and a CD-ROM disk, it should be 45 ^"PP°'^ ''^^^"^ protocols, including, but not lim- 
appreciated by those skilled in the art that other types of ^^^^ protocols known in the art such as Internet Message 
media which are readable by a computer, such as magnetic Access Protocol (IMAP), version 3.0 of Post Office Protocol 
cassettes, flash memory cards, digital video disks, BernouUi (P^^^), Simple Mail Transfer Protocol (SMTP), Multipur- 
cartridges, and the like, may also be used in the exemplary Po^e Internet Mail Extensions (MIME), and Hyper Text 
operating environment. 50 ^'^*^P Language (HTML). 

A number of program modules may be stored in the drives In FIG. 3, a remote computer 49 operates as a server and 
and RAM 25, including an operating system 35, one or more generally includes an e-mail server application 110, a local 
application programs, such as an e-mail program module 36, store 115, and a client manager control 120. In an exemplary 
other program modules, such as a message manager pro- embodiment, the server 49 is a P0P3 mail server, but it will 
gram module 37, a local message store 38, and a database 39 55 be appreciated that the present invention is not limited to this 
for supporting e-mail applications. A user may enter com- lyP^ server. In the exemplary embodiment, the chent 20 
mands and information into the client 20 through a keyboard includes a local message store 38, a database 39, an e-mail 
40 and pointing device, such as a mouse 42. Other input program module 36, and a message manager program mod- 
devices (not shown) may include a pen, touch-operated ule 37 for facilitating message management and operation of 
device, microphone joystick, game pad, satellite dish, 60 the database 39. 

scanner, or the like. These and other input devices are often With respect to the exemplary embodiment, the client 20 

connected to the processing unit 21 through a serial port provides two modes of operation in connection with the 

interface 46 that is coupled to the system bus, but may be server 49. These modes are a default mode and a "leave on 

connected by other interfaces, such as a game port or a server*' mode. In the default mode, the client 20 sends a 
universal serial bus (USB). A monitor 47 or other type of 65 delete command to the server 49 to delete a message from 

display device is also connected to the system bus 23 via an the server 49 after the message has been downloaded to the 

interface, such as a video adapter 48. In addition to the client 20. In the "leave on server" mode, the client does not 
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send a delete command to the server 49 after the message 
has been downloaded to the client 20, thereby allowing the 
message to remain on the server 49 although the message 
has been downloaded. The mode of operation generally is 
selected based on user-preference. Advantageously, the 
present invention optimizes the management of messages 
when the client 20 is in the "leave on server" mode, as will 
be described below in connection with FIGS. 4-8. 

The server 49 houses any e-mail messages from clients in 
the local store 115 while awaiting transmission to an appro- 
priate destination. The e-mail server application 110 for- 
wards messages over the WAN 52 from a sender client (not 
shown) to the client 20, upon request by the client 20. The 
client manager control 120 is a program used to set up 
computer systems, such as clients 1, Ua, Ufr, 11c (FIG. 1), 
and 20 (FIG. 2) on the network. The client manager control 
120 can also specify the addresses of the computer systems 
located on the network. In addition, the client manager 
control 120 typically facilitates the management of incom- 
ing and outgoing messages on the server. When a request for 
a message is made by the client 20 to the server 49, the 
e-mail server application 110 on the server 49 responds by 
retrieving the message from the local store 115 on the server 
49 and by transmitting the message over the WAN 52 to the 
client 20. The message is then downloaded into the local 
message store 38 located at the client 20. The local message 
store 38 houses all downloaded messages from the server 49. 

During the download operation, data fields are populated 
within the database 39 with message-related information 
associated with the downloaded message. The information 
includes a unique identifier for identifying the message, a 
session identifier for indicating the particular order in which 
the message is retrieved from the server, a message size and 
other message-related information that will be described in 
greater detail herein below with respect to FIGS. 4-8. The 
e-mail program module 36 provides facilities for creating, 
addressing, sending, receiving, and forwarding messages, 
while the message manager program module 37 manages 
messages during download and deletion operations utilizing 
the database 39. The use of the database 39 is described in 
greater detail in connection with FIGS. 4a-4k, collectively 
described as FIG. 4. 

With continuing reference to FIGS. 1-3 and now turning 
to FIGS, 4fl-4/r, a client-based database used in connection 
with the exemplary program module 37 is illustrated. FIGS. 
4a~4k illustrate a client-based database for archiving mes- 
sages in accordance with an exemplary embodiment of the 
present invention. 

The database 39 can include multiple data fields, orga- 
nized within an array structure, for maintaining message - 
related information. To support download and delete 
operations, typical data fields of the database include: a 
session identifier (session ID) 200, a unique identifier 
(UIDL) 205, a message size 210, an entry identifier (EID) 
215, a receive date and time 220, which is the local machine 
time, an "on server" flag 225, a "download" flag 230, and a 
"delete" flag 235. Message re-assembly operations can be 
supported by adding to the database structure certain data 
fields corresponding to portions of a MIME-compatible 
message, such as a message group identifier (message group 
ID) 240, a message part number 245, and a total parts 
number 250. 

Operation of the database 39 in connection with the 
message manager program module 37 (FIG. 3) is presented 
by way of a representative example. In this example, a 
connection is made between a client 20 (FIG. 3) and server 
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49 (FIG. 3). A user desires to check her e-mail messages for 
the first time and is typically prompted by the e-mail 
program module 36 (FIG. 3) to enter a password for access 
to the e-mail messages. 

5 Referring to FIG. 4a, the server 49 contains two messages 
in its local store 115. In an initial download operation, the 
client 20 transmits a UIDL command to the server 49. The 
UIDL command is a request for identification information 
associated with a message. Each message has its own unique 
identifier or UIDL to identify the message. It will be 
appreciated by one skilled in the art that the present inven- 
tion is not limited to transmitting a UIDL command to the 
server to obtain identification information associated with a 
message, but may instead transmit other commands, such as 
a TOP command or a LIST command, to obtain such 
identification information. Furthermore, it will be appreci- 
ated that the present invention is not limited to transmitting 
only one command, such as a UIDL command, to obtain 
identification information, but may transmit thereafter, other 

2p commands, such as a TOP command or a LIST command, 
if the server fails to respond to the initial UIDL command for 
obtaining such information. 

In response to the UIDL command, the client 20 retrieves 
from the server a session ID and the requested UIDL for the 

25 first message on the server. The session ID is indicative of 
the particular order in which the message is retrieved from 
the server during a specific download operation. In this 
example, the client retrieves session ID "1" and UIDL 
"abed" for the first message. The session ID 200 and UIDL 

3Q 205 fields for a first entry in the database 39 are populated 
with the session ID and the UIDL for the first message. In 
response to populating the data fields with the UIDL and the 
session ID, an "on server" flag is set to a true state "T" in the 
message entry for the first message. 

35 The "on server" flag exists in three states — a true state, a 
false state, and an unknown state. The true slate serves as an 
indicator that the message associated with the message entry 
is located on the server. The false state serves as an indicator 
that the message associated with the message entry is not 

40 located on the server. ^Fhe unknown state is indicative of the 
beginning of a client-server session or initialization of the 
message manager program module 37 (FIG. 3). Specifically, 
in the unknown state, all "on server" flags for message 
entries in the database are cleared prior to the start of 

45 download operations. In an exemplary embodiment, the 
message manager program module 37 (FIG. 3) changes all 
"on server" flags to unknown states when the message 
manager program module 37 (FIG. 3) is initialized. 
Advantageously, performing this task before a connection is 

50 made between the client and server eliminates unnecessary 
consumption of time during a client-server session. Hoverer, 
it will be appreciated by one skilled in the art that the 
message manager program module can change an "on 
server" flag for a message entry to an unknown state after a 

55 connection is made between a client and server. 

After the "on server" flag is set to a true state, the client 
20 retrieves the session ID and UIDL for a second message 
on the server 49. In this example, the session ID is "2" and 
the UIDL for the second message is "efgh". Again, the data 

60 fields 200 and 205 for a second entry are populated with the 
appropriate data, and an "on server" flag is set to a true state 
"T** in the database for this second message. If there are 
more messages on the server, this process is repeated for the 
additional messages to complete the initial download opera- 

65 tion. 

Once the session ID and UIDL have been populated in the 
database 39 for each message, the client 20 checks for a size 
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restriction in connection with downloading messages from entries marked with a "delete" flag are located in response 
the server 49. A size restriction for downloading messages to walking the message entries in the database 39 and 
from the server can be set at any time based on user- thereafter, are deleted from the server 49. These message 
preference. For example, it may be desirable to set a entries are not identified until all message retrieval opera- 
maximum size Umit for downloading a message when a user 5 tions are completed during this connection. In this example, 
has only a small amount of time to check messages, there are no entries to be deleted during this connection. The 
Consequently, the user may prefer to view messages of a ^Uent 20 is then disconnected from the server 49. 
certain size at another time. In a scenario where a size n r • * t-t.^ ># l r *l * j 1 j 

^ . - * r -1 1 J- *i. 1- * ->A Referring to FIG. 4c, before the next download operation 

restriction is set for downloadmg messages, the client 20 . ^ • • . • ^ r . 

t.,«^™;tc o T TCT t.^ «tr -„- o i;.t occurs, the session IDs in the session ID field 200 of the 

transmits a Llol command to retrieve a list 01 message 1 j. .--i- 

J , «u . f II -.u- *u . ° 10 database 39 are cleared because this mformation is based on 

sizes, and only those messages that fall withm the maximum . , . , . , , 

^ „i J 1 • * *u „ the last client -server session and is no longer useful. In 

size limit set by the user are downloaded mto the message , . „ „ « ■ « a ^ u 

f J 1 ^- • « 4L addition, each on server flag m the on server flag field 

store 38. The process of downloadmg a message into the . ! , ^ , 

• • . • . 225 is changed from a true state i to an unknown state 

message store in connection with setting a size restriction is ^ "6 " "^"^ « luv o v * i^ukj 

described in more detail below in connection with FIGS. ^ message entry. 

Turning to FIG. 4</, in a subsequent download operation, 

In this example, the client 20 does not find a size the cUent 20 and server 49 are again connected, as descn^^^ 

restriction set by the user. Consequently, the client 20 above in FIG. 4a Tliere are now five messages in the local 

transmits a RETR command to the server 49. The RETR located on the server 49. three of which are new 

command is a request to retrieve a message from the server ^ "J^^"!^^ ""at have not been previously downloaded to the 

into a local message store 38 located at the client 20. Each ^ 

message is then downloaded into the local message store 38, Th® client 20 transmits a UIDL command to the server 49. 

Turning to FIG. 4b, in response to each downloaded response to the UIDL command, the client 20 retrieves 
message, additional data fields 210, 215. 220. 230, 240, 245. ^""^ ^^^^ ^ requested UIDL for the 
and 250 in the database entries are populated with message- ,5 "^f^^S^ ^^^^^^ ^nce the chent retrieves the 
related information associated with the message. UIDL from the server 49 the UIDL is compared to each 
Specifically, a message size for the message is populated in ^^^^^y ^^^^^^^ determine whether the 
the message size field 210, an entry identifier is populated in T^ln^^cd from the server matches any of the UIDU 
the EID field 215, and a receive date and time for the ^^^^^^^ ^^^'^ ^ f^^^^^' ^ 1° ^ 
message is populated in the receive date and time field. In 30 appended to the menage entry havmg the matching UIDL, 
addition, with respect to multiple part messages, a message ^""^ is changed from an unknown state 
group identifier is populated in the message group ID field ^ ^"^^ ^tate T m the database as a part of the 
240, a message parts number is populated in the message ^^^^^ ^^^^ ^.^^"^^^^^ ^^"^ server does 
parts number field 245, and a total parts number is populated "^^^^h any of the UIDU in the database, the data fields 
in the total pa its field 250. In this example, the message- 35 """^ ^""^ ^ ^'"^ "^^"^^^ ^"^"^ "".^^ 
related information for a message entry associated with the populated with the UIDL and the session ID, and an on 
first message includes: message size "100", entry identifier >^ ^« ^ ^"^^ ^ i^e database 39 as a 
"1", time and date "12/1/97 12:00:00", The message-related f J^e message entry. This step of coinparing UIDLs 
information associated with the second message includes: the server 49 with UIDLs in the database 39 is 
message size "50'\ entry identifier "2", time and date 40 P^^^""^^ ^^^^ °° ^^^^ 
"12/1/97 12:01:00". In response to downloading the mes- As shown in FIG. 4^, session IDs are appended for 
sages to the local message store 38, a "Download" flag is set message entries having UIDLs "abed" and "efgh" because 
in the database 39 for each downloaded message in the message entries were previously entered in the database 
"download" flag field 230. This flag simply indicates that the 39 and the associated messages have already been down- 
message has been downloaded from the server 49 to the 45 loaded as reflected in the "download" flag field 230. The 
client 20. Consequently, the database 39 contains two mes- Itiree remaining message entries are new and contain only 
sage entries associated with the downloaded messages. the session ID. the UIDL, and an "on server" flag in a true 

Before disconnecting the communication between the ^^^^^ ^ • 

client 20 and server 49, a "delete" flag can be set for a Specifically, session ID "3" has a UIDL of "ijkl", session 

message entry of the database 39 in response to the user 50 ID "4" has a UIDL of "mnop", and session ID "5" has a 

dragging a representation of the corresponding message to a UIDL of "qrst", 

trash can presented via the GUI. In addition, a "delete" flag Once the respective session ID and UIDL have been 
is automatically set for each message entry when the client populated for the new messages and the session ID has been 
is in a default mode, where a message is deleted from the appended to previously entered message entries in the 
server after it has been downloaded. The user also can set a 55 database 39, the client 20 checks for a size restriction in 
time-based parameter in the message manager program connection with downloading messages from the server 49. 
module 37 that defines a time period for expiring aU mes- In this example, the client 20 does not find a size restriction, 
sages maintained in the local message store 38 after a As a result, the client 20 transmits a RETR command to the 
pre-defined time period. Because the database 39 maintains server 49. Each new message is then downloaded into the 
local time entries for each message, those messages satis- 60 local message store 38. In other words, only the messages 
fying the pre-defined time period for expiration can be that have associated message entries with a cleared "down- 
marked with a "delete" flag. In this example, the user has set load" flag are downloaded into the local message stole 38. 
a seventy-two hour time period for expiration of a message In FIG. 4d, messages having UIDLs "ijkl", "mnop", and 
and its associated message entry. "qrst" are downloaded. 

Message entries containing "delete" flags in the database 65 Turning to FIG. 4e, in response to each downloaded 

39 can be deleted from the server 49 after all message message, a message size for the message is populated in the 

retrieval operations are completed. In particular, all message message size field 210, an entry identifier is populated in the 
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EID field 215, and a receive date and time for the message from the server a session ID and the requested UIDL for the 
is populated in the receive date and time field. Specifically. each message on the server. Once the client retrieves the 
UIDL "ijkl" has a message size of 150, an EID of 3, a date UIDL from the server 49, the UIDL is compared to each 
and time of "12/4/97 13:00:00; UIDL"mnop" has a message UIDL in the database 39 as previously described in connec- 
size of 300, an EID of 4. a date and time of "12/4/97 5 tion with FIG. 4d. If there is a match, a session ID is 
13:01:00; and UIDL "qrst" has a message size of 250, an appended to the message entry having the matching UIDL, 
EID of 5, a date and time of "12/4/97 13:02:00. In addition, and an "on server*' flag is set to a true state "P* in the 
with respect to multiple part messages, a message group database as a part of the message entry. As shown in FIG. 4A, 
identifier is populated in the message group ID field 240, a session IDs are appended for message entries having UIDLs 
message parts number is populated in the message parts 30 "abed", "ijkl", and "mnop". As previously mentioned, the 
number field 245, and a total parts number is populated in message associated with the message entry having UIDL 
the total parts field 250. In FIG. 4e, message entries having "qrst" is no longer on the server. Therefore, a session ID is 
UIDLs "ijkl" and "mnop" are associated with a message not entered for a corresponding message entry in the data- 
having multiple message parts, as indicated by the message base 39, and the "on server*' flag is changed from an 
group identifier, the message parts number, and the total is unknown state "U" to a false state "F". 
parts number in the data fields 240, 245. and 250, respec- u the UIDL retrieved from the server does not match any 
lively. In particular, message entries having UIDLs "ijkl" of the UIDLs in the database, the data fields 200 and 205 in 
and "mnop" have a common message group identifier of the database 39 are populated with the UIDL and the session 
"zcy" and are labeled with message part numbers "1" and id for each message, and an "on server" flag is set to a true 
"2", respectively, of total parts number "2". When present- 20 state "T" in the database 39 as a part of the message entry, 
ing the message associated with message entries having As shown in FIG. 4/i, there is only one new message having 
UIDLs "ijkl" and "mnop", message re-assembly is required. UIDL "uvwx" and session ID "4". 
Message reassembly occurs preferably after the cUent-server Once the respective session ID and UIDL have been 
session is completed. Message re-assembly will be populated for the new messages and the session ID has been 
descnbed in greater detail below m connection with FIG. 8. 25 appended to previously entered message entries in the 

In response to downloading the new messages to the local database 39, the client 20 checks for a size restriction in 

message store 38,^a "download" flag is set in a message entry connection with downloading messages from the server 49. 

of the database 39 for each downloaded message in the in this example, the client 20 does not find a size restriction, 

"download" flag field 230. Consequently, the database 39 As a result, the client 20 transmits a RETR command to the 
now contains five message entries associated with the pre- 30 server 49. The new message is then downloaded into the 

viously and newly downloaded messages. local message store 38. In FIG. 4/i, the message having 

Before disconnecting the communication between the UIDL "uvwx" is downloaded, 
client 20 and server 49, a "delete" flag is set for all message Turning to FIG. 4i, in response to the downloaded 

entries that have expired based on the period of time set by message, a message size of "180" for the message is 

the user. As previously mentioned, the user set a time period populated in the message size field 210, all entry identifier 

of seventy-two hours. This determination is made by com- of "6" is populated in the EID field 215, and a receive (late 

paring the date and time located in the date and time field for and time of "12/5/97 08:00:00** for the message is populated 

each message entry to the preset period of time. If the preset in the receive date and time field. There is no message group 

period of time has expired for a message entry, the message identifier, message parts number, or total parts number for 

entry is then marked for deletion. In FIG. 4e, none of the the downloaded message. 

message entries has expired. Therefore, a delete flag is not response to downloading the new message to the local 
set for any of the message entries. In FIG. 4e, the user has message store 38, a "download" flag is set in the database 39 
also set for deletion the second message entry having UIDL for the downloaded message in the "download" flag field 
"efgh". As a result, a "delete" flag is set in the "delete" flag 230. Consequently, the database 39 now contains five mes- 
field 235 for the corresponding entry in the database 39. sage entries associated with the previously and newly down- 
Next, the client 20 transmits a DELETE command to the loaded messages. 

server 49 to remove all messages firom the server 49 and 3,^,^ disconnecting the communication between the 

associated message entnes m the database having a 'delete ^^^^j 20 and server 49, a "delete" flag is set for all message 

flag. In FTG. 4/ the message entry havmg UIDL "efgh" is .^^^es that have expired based on the period of time set by 

removed from the database 39 and the associated message is the user. As previously mentioned, this determination is 

removed from the server 49 Also, before disconnecting the ^^^^ ^y comparing the date and time located in the date and 

client 20 from the server 49. the user may decide to delete time field for each message entry to the preset period of time, 
the message having UIDL "qrst" from the server. The client ^^^^^ time has expired for a message entry, 

20 is then disconnected from the server 49. the message entry is then marked for deletion. In this 

Referring to FIG. 4g, before the next client-server con- example, the message entry having UIDL "abed" is marked 

nection is established, each session ID in the session ID field for deletion as indicated in the "delete" flag field 235. 
200 is cleared and each "on server" flag in the "on server" ^ext, the client 20 transmits a DELETE command to the 

flag field 225 is set to an unknown state "U" for each ^^^j. 49 to remove all messages from the server and 

message entry. associated message entries in the database having a "delete" 

Now turning to FIG. 4^, in a subsequent download and flag. In FIG. 4y, the message entry having UIDL "abed" is 

delete operation, the client 20 and server 49 are again removed from the database 39 and the associated message is 

connected. There are now four messages in the local store removed from the server 49. 

115 located on the server 49, one ofwhich is a new message Once aU message entries having a "delete" flag are 
that have not been previously downloaded to the client 20. 55 removed from the database or if there are no message entries 

The client 20 transmits a UIDL command to the server 49. having a "delete" flag, the client 20 is disconnected from the 

In response to the UIDL command, the client 20 retrieves server 49. 
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Referring to FIG. 4k, after the client 20 is disconnected able to avoid downloading a message twice, thereby solving 

from the server 49, each message entry having an "on an efficiency problem prevalent in prior systems, 

server" flag in a false state "F" is deleted from the database with continuing reference to FIGS. 1-4, FIGS. Sa-Sc, 

39 because the associated message is no longer located on collectively described as FIG. 5, are flow diagrams illus- 

the server. In this case, the message entry having UIDL 5 trating an exemplary process for an initial download opera- 

"qrst" is removed from the database 39, as shown in FIG. 4k. tion utilizing a database in accordance with an exemplary 

In summary, a typical communication between the client embodiment of the present invention. Those skilled in the art 

20 and server 49 is supported by database operations con- will appreciate that the exemplary process is carried out by 

ducted by a message manager program module 37 of the a client using an application program 36 (FIG. 2), such as the 

e-mail message program 36 running on the client 20. In 10 "MICROSOFT OUTLOOK '98" program. The 

response to message-related information transmitted by the "MICROSOFT OUTLOOK '98" program has a message 

server 49 (session ID and UIDL), the message manager manager program module 37 (FIG. 3), which is operative to 

program module 37 creates a message list by creating, communicate with the remote mail server 49 (FIG. 3). In this 

message entries in the database 39 and fillling the session ID embodiment, the client, the remote mail server, and the local 

200 and UIDL 205 fields for these entries. In response to the message store implement an Internet protocol and operate in 

client 20 deceiving a downloaded message, the message an on-line mode. In addition, the remote mail server is in a 

manager program module 37 populates selected fields of the "leave on server" mode. 

message entry conesponding to the downloaded message. At the START step 300, the exemplary program module 

Advantageously, the message manager keeps track of the is initialized and a connection is made between the client and 

downloaded message and updates the database as the status 20 jj^g server, typically via a modem, for communication. Also, 

of the message changes. at START step 300, a log-in procedure typically occurs, 

After retrieving all identified messages, but prior to ter- where a user is prompted to enter a password, and the 

minating the communication operation the message man- password is verified by the program module, 

ager program module 37 searches the database 39 for entries For an initial download operation, the client transmits a 

containing a "delete" flag. For each message entry having a UIDL command to the server, in step 305. The UIDL 

"delete" flag, the message manager program module 37 command is a request for identification information associ- 

instructs the e-mail message program 36 to send a DELETE ated with a message. Each message preferably has its own 

command for messages on the server corresponding to the unique identifier or UIDL to identify the message, 

message entries having "delete" flags. in response to the UIDL command, in step 310. the client 

Advantageously, by also maintaining information in the retrieves from the server a session ID, as well as the 

database regarding message deletion, the message manager requested UIDL for a message on the server. The session ID 

program module serves as an effective and efficient man- or session identifier is indicative of the particular order in 

agement mechanism for messages. Whereas in prior which the message is retrieved from the server during, a 

systems, separate routines are usually needed to handle ^5 specific download operation. Next, in step 315, data fields in 

download, deletion, time expiration, message size the client -based database are populated with the UIDL and 

restriction, and reassembly operations, the present invention the session ID. The population of data fields during specific 

provides a single mechanism for managing all of these steps in the process of FIG. 5 will be described in greater 

operations, namely the message manager program module. detail herein below in connection with FIGS. 6a and 6b. 

It will be appreciated by those skilled in the art that FIG. 40 In response to populating the data fields with the UIDL 

4 shows only a representative example of the present inven- and the session ID, in step 320, an "on server" flag is set to 

tion and does not in any way limit the present invention to a true state in the database for the message. In the true state, 

that example. For instance, the present invention can com- the "on server" flag serves as an indicator that the message 

bine commands such as UIDL and RETR such that each associated with the message entry is located on the server, 

command is provided alternately for each message. Further, 45 A determination is then made, in step 325, as to whether 

it will be appreciated that the present invention is not limited there are ant additional messages located on the server. If 

to the data fields presented in this example, but may also there are additional messages located on the server, the 

include various other data fields containing information "YES" branch is followed to step 310; otherwise, the "NO" 

associated with messages. ' branch is followed to step 326. In step 310, the client 

The present invention provides the benefit of maintaining 50 retrieves the session ID and UIDL for the next message from 

the current status of messages on the server. the server. Next, the data fields in the database arc populated. 

Advantageously, messages that have already been down- in step 315, with the information retrieved from the server 

loaded fi-om the server to the local message store are not for this message, and, in step 320, an "on server** flag is set 

downloaded again. In some prior systems, a message is to the true state in the database for this message. This 

generally downloaded twice if a connection between the 55 process is repeated for each successive message located on 

client and server is accidentally discontinued during a down- the server. A message entry list is effectively created in the 

load operation. These prior art systems typically do not keep database. 

track of the download process. However, the present inven- Turning briefly to FIG. 6fl, an exemplary process of 

tion provides the benefit of storing, in a client-based populating data fields is shown, where steps 405 and 410 

database, not only the message-related information for the 60 represent the process of populating data fields as described 

message, but also the status of the message, for example in connection with step 315 of FIG. 5. In step 405, a session 

whether the message has been downloaded, whether the ID field is populated with the session ID retrieved in step 

message is present on the server, and so forth. Consequently, 310 (FIG. 5fl). Next, in step 410, a UIDL field is populated 

when a client-server session is abrupdy discontinued and with the UIDL retrieved in step 310 (FIG. 5fl). 

later re-established, the present invention is able to conve- 65 Now, turning back to FIG. 5a, once the session ID and 

niently start at the point where it left ofl: by consulting the UIDL have been populated in a message entry for each 

client-based database. Therefore, the present invention is message, a determination is made as to whether there is a 
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size restriction set in connection with downloading mes- is disconnected from the server. In step 370, any messages 

sages from the server. If there is no size restriction set, the having multiple parts are reassembled. The initial download 

"NO" branch is followed to step 330 (FIG. Sb); otherwise, process terminates at the END step 371. 

the "YES" branch is followed to step 327 (FIG. 5c). Turning to FIG. 6b, an exemplary process of populating 

In FIG. Sb, the client transmits a RETR command to the 5 data fields is shown, where steps 420, 425, and 430 represent 
server, in step 330. The RETR command is a request to the process of populating data fields as described in con- 
retrieve or download a message from the server into a local nection with steps 340 and 364 of FIGS. 5b and 5c, 
message store located at the client. Next, a first message respectively. Specifically, a message size for the message is 
associated with the first UIDL is downloaded from the server populated in a message size field, in step 420. Next, an entry 
into the local message store, in step 335. lO identifier is populated in an EID field, in step 425. Finally, 

In response to the downloaded message, data fields are a date and time is populated in a date and time field in step 

then populated, in step 340, in the database with specifica- 430. It wUl be appreciated by those skilled in the art that the 

tion information, such as message size and receive date and present invention is not limited to this particular order of 

time, associated with the message. The population of sped- populating data fields. Furthermore, it will be appreciated 

fication information will be described in greater detail below that the message size for a message can be populated in the 

in connection with FIG. 6b. Next, a "download" flag is set message size field immediately after obtaining the list of 

in the database for the downloaded message, in step 345. message sizes (step 328, FIG. 5c) instead of populating the 

This flag simply indicates that the message has been down- message size field with the message size at step 364 (FIG. 

loaded. 5^)- 

Next, a determination is made, in step 350, as to whether FIGS. la-7d, collectively described as FIG. 7, are flow 

there are any more messages to be downloaded to the client. diagrams illustrating an exemplary process of downloading 

This determination is based on the number of session ID and and deleting information subsequent to an initial download 

UIDL entries in the database that were obtained during steps operation in accordance with an exemplary embodiment of 

310 and 315. If there are more messages to be downloaded, the present invention. 

the "YES" branch is followed to step 330, in which case a In FIG. 7fl, at the START step 500, an exemplary program 

RETR command is sent to retrieve the next message. Step module is initialized, and in step 501, the chent clears or 

330 through step 345 are repeated for the next message, and zeroes all session IDs in the database because a new session 

each message thereafter to complete the download process. is about to begin and this information is no longer needed. 

If there are no more messages to be downloaded, the Next, all "on server" flags are set to an unknown state, in 

"NO" branch is followed to step 369. In step 369, the cUent step 502. 

is disconnected from the server. In step 370, any messages In step 503, a connection is made between the chent and 

having multiple parts are reassembled. The initial download the server for communication, and a log-in procedure typi- 

process terminates at the END step 371. cally occurs, where a user is prompted to enter a password, 

Referring to FIG. 5c, if there is a size restriction set for and the password is verified by the exemplary program 

downloading messages, the client transmits a LIST module. 

command, in step 327. The LIST command is a request to In step 505, the chent transmits a UIDL command to the 

retrieve a fist of all message sizes for the messages that may server. In response to the UIDL command, in step 510, the 

be downloaded from the server. The messages are then chent retrieves firont the server a session ID, as well as the 
listed, in step 328. ^ requested UIDL for a message on the server. 

Next, a determination is made, in step 329, as to whether Once the client retrieves the UIDL from the server, the 

the message size for a first message is greater than a UIDL is compared to each message entry in the database, in 

maximum size hmit set based on user-provided input. If so, step 515. A central inquiry is made, in step 520, as to 

the message is not downloaded and the "YES" branch is whether the UIDL retrieved from the server matches any of 
followed to step 368; otherwise, the "NO" branch is fol- 45 the UIDLs in the database. If there is a match, the "YES" 

lowed to step 360, in which case, a RETR command is branch is followed to step 525; otherwise, the "NO" branch 

transmitted to the server to download a message from the is foUowed to step 540. In step 525, a session ID is appended 

server into the local message store. Next, the message to the message entry having the matching UIDL in the 

associated with the message size is downloaded from the database. Next, in step 545, an "on server** flag, is set to a 
server into the local message store, in step 362. 5Q true state as a part of the message entry, which is associated 

In response to the downloaded message, data fields are with the message on the server. The true state indicates that 

then populated, in step 364, in the database with specifica- the message associated with the message entry is on the 

tion information, such as message size and receive date and server. 

time, associated with the message. The population of speci- If the UIDL retrieved firom the server does not match any 
fication information will be described in greater detail below 55 of the UIDLs in the database, in step 540, the data fields in 

in connection with FIG. 6b, Next, a "download" flag is set the database are populated with the UIDL and the session 

in the database for the downloaded message, in step 366. ID. In response to populating the data fields with the UIDL 

Next, a determination is made, in step 368, as to whether and the session ID. in step 545, an "on server** flag is set to 

there are any more message sizes in the messages size list. a true state in the database as a part of the message entry. 
If there are more message sizes, the "YES** branch is 60 which is associated with the message on the server, 

followed to step 329. In step 329, a determination is made Next, a determination is made, in step 550, as to whether 

as to whether the message size for the next message is there are any additional messages located on the server. If 

greater than the maximum size limit set. Step 360 through there are additional messages located on the server, the 

step 368 are repeated for the next message, and each "YES" branch is followed to step 510, where the chent 
message thereafter. 65 retrieves the session ID and UIDL for the next message from 

If there are no more message sizes in the message list, the the server; otherwise, the "NO** branch is followed to step 

"NO" branch is followed to step 369. In step 369, the client 551, in which case, the client changes all "on server*' flags 
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that are in unknown states to false states to indicate that 
these message entries do not have associated messages on 
the server. 

Next, a determination is made as to whether there is a size 
restriction set in connection with downloading messages 
from the server. If there is no size restriction set, the "NO" 
branch is followed to step 555 (FIG. 7b); otherwise, the 
"YES" branch is followed to step 576 (FIG. 7c). 

In FIG. 7b, the client transmits a RETR command to the 
server, in step 555, to download the message associated with 
the UIDL from the server into a local message store located 
at the client. Next, the message associated with the UIDL is 
downloaded from the server into the local message store, in 
step 560. 

In response to the downloaded message, data fields are 
then populated, in step 565, in the database with the message 
size, the entry ID, and the receive date and time, all of which 
are associated with the message. Next, a "download" flag is 
set in the database for the downloaded message, in step 570, 
to indicate that the message has been downloaded. 

A determination is then made, in step 575, as to whether 
there are any more messages to be downloaded onto the 
client. This determinatioin is based on the number of session 
ID and UIDL entries in the database that were populated 
during step 540. If there are more messages to be 
downloaded, the "YES" branch is followed to step 555, in 
which case a RETR command is sent to retrieve the next 
message. Step 560 through step 570 are repeated for the next 
message, and each message thereafter to complete the down- 
load process. If there are no more messages to be 
downloaded, the "NO" branch is foUowed to step 592 (HG. 
Id), 

Turning to FIG. 7c, alternatively if there is a size restric- 
tion set for downloading messages, the client transmits a 
LIST command, in step 576. The messages are then listed, 
in step 578. 

Next, a determination is made in step 580, as to as 
whether the message size for a first message is greater than 
a maximum size limit set based on user-provided input. If so, 
the message is not downloaded and the "YES" branch is 
followed to step 590; otherwise the "NO" branch is followed 
to step 582, in which case, a RETR command is transmitted 
to the server to download a message from the server into the 
local message store. Next, the message associated with the 
message size is downloaded from the server into the local' 
message store, in step 584, 

In response to the downloaded message, data fields are 
then populated, in step 586, in the database with specifica- 
tion information, such as message size and receive date and 
time, associated with the message. Next, a "download" flag 
is set in the database for the downloaded message, in step 
588. 

Next, a determination is made, in step 590, as to whether 
there are any more message sizes in the messages size list. 
If there are more message sizes, the "YES" branch is 
followed to step 580. In step 580, a determination is made 
as to whether the message size for the next message is 
greater than the maximum size limit set. Step 582 through 
step 590 are repeated for the next message, and each 
message thereafter. If there are no more message sizes in the 
message list, the "NO" branch is followed to step 592 (FIG. 

Id). 

Referring to FIG. Id, a determination is then made, in step 
592, as to whether the client is in a "leave on server" mode. 
If the client is in a "leave on server" mode, the "YES"braach 
is followed to step 596; otherwise, the "NO" branch is 
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followed to step 594, in which case, "delete" flags are set for 
all message entries in the database. 

Once it is determined that the client is in a "leave on 
server*' mode, another determination is made, in step 596, as 

5 to whether a preset period of time has expired for any of the 
message entries. This determination is made by comparing 
the date and time located in the date and time field for each 
message entry to the preset period of time allowed for a 
message entry to remain in the database. If the preset period 

10 of time has expired for a message entry, the "YES" branch 
is followed to step 598, where a "delete" flag is set for the 
message entry; otherwise, the "NO" branch is followed to 
step 599. Step 598 is repeated for each message entry that 
has expired. 

In step 599, a central inquiry is made as to whether there 
are any message entries in the database that have a "delete" 
flag. If there is a message entry having a "delete" flag, the 
"YES" branch is foUowed to step 600; otherwise, the "NO" 
branch is followed to step 610. In step 600, the client 

'^^ transmits a DELETE command to the server to remove the 
message from the server. Next, in step 605, the message is 
removed from the server, and the associated message entry 
is removed from the database. Steps 600 and 605 are 
repeated for each message entry having a "delete" flat. 

In step 610, the client is disconnected from the server. 
After the client-server session has ended, in step 615, each 
message entry having an "on server" flag set to a false state 
is deleted from the database because a corresponding mes- 
sage is no longer located on the server Next, in step 617, any 
messages having multiple parts are reassembled. The pro- 
cess terminates at the FND step 620. 

In summary, for each subsequent download session, the 
session ID fields in the database are zeroed or otherwise 

35 cleared, all "on server" flaps are set to an unknown state for 
each message entry in the database, and a UIDL command 
is transmitted by the client to the server In response to the 
UIDL command, the server transmits to the client session ID 
and UIDL information for each message on the server. The 

^ UIDL information comprises a list of messages available on 
the server for downloading to the client. The database is 
checked to determine whether the messages on the server, as 
identified by corresponding UIDLs, have been previously 
retrieved by the client in a prior download operation. 

45 In the event that the UIDL obtained in response to the 
UIDL command is stored as an entry in the database, then 
the message has been previously downloaded to the local 
message store at the client. Consequently, the session ID is 
appended to the message entry corresponding to this UIDL, 

50 and the "on server" flag, which was initially set to an 
unknown state, is now set to a true state. Because the 
"download" flag for this message entry was previously set, 
the message identified by this UIDL is not retrieved — that is, 
the RETR command is not transmitted to the server for 

55 message entries having a " download" 

On the other hand, if the UIDL is not present in the 
database, then the associated message is treated as a new 
message. A message entry for the message is then created in 
the database by populating the session ID and the UIDL 

60 fields and by setting the "on server" flag to a true state. If 
there is a size restriction set based on user-provided input, 
the client transmits a LIST command to the server to provide 
a list of the message sizes for messages on the server Only 
the messages that fall within the size restriction are then 

65 downloaded from the server to a local message store located 
at the. client. To download a message from the server to the 
client, the client transmits a RETR command to the server 
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In response to each downloaded message, the message size, 
entry ID, received date/time data fields are populated, and 
the "download" flag is set. In this manner, only those 
messages on the server that represent new messages, i.e., 
messages not previously transmitted to the client, are 
retrieved for storage in the local message store. 

An "on server** flag remaining in an unknown state for a 
message entry is changed to a false state during the down- 
load operation, and the message entry is later deleted from 
the database to avoid maintaining message-related informa- 
tion at the client for messages not available on the server. In 
addition, message entries having a "delete" flag and message 
entries that have remained in the database for a preset period 
of time are removed from the database. After completing the 
download operation, server-client communication is discon- 
nected. 

Advantageously, the present invention provides a data- 
base for maintaining archival message-related information 
for each message, which is identified by a UIDL and 
maintained on the server. The database then is used to 
manage messages maintained on the server. Moreover, the 
present invention provides several management features, 
including download, delete, time expiration, and message 
reassembly features, within a single program module, 
namely the message manager program module, as opposed 
to maintaining separate program modules program these 
features, as do prior systems. 

MESSAGE REASSEMBLY 

To assemble a message comprising multiple message 
parts, the present invention performs a search of selected 
fields in a central database, namely a message manager 
database, maintained at the client. These fields represent 
additions to the database described in connection with FIGS. 
4-7. These fields include (1) message group ID, (2) message 
part number and (3) total parts fields. The values of these 
fields are placed in any MIME-compatible message. The 
database is searched to locate all message entries having the 
same value for the message group ID, which serves as a 
unique identifier for the message. The messages in the local 
message store are selected in response to the located mes- 
sage entries in the database and organized in proper message 
order based on the values of the message part number. The 
total parts value places a maximum limit on the number of 
message parts needed to complete the multi-part message. 
Accordingly, the message parts are assembled to form a 
single, reassembled message,' which is then presented to the 
user. In an exemplary embodiment, message entries for 
messages containing muhiple message parts are not typi- 
cally removed from the database until the message his been 
reassembled or unless a predefined time period for the 
message entries to remain in the database has expired. 

Turn now to FIG. 8, which is a flow diagram illustrating 
an exemplary process for reassembling a message having 
multiple message parts in accordance with an exemplary 
embodiment of the present invention. The process begins at 
the START step 700 by turning on the client 20 and selecting 
an exemplary application program that supports a message 
manager program module for implementing the exemplary 
process. In addition, a connection is made between the chent 
and the server to retrieve a message having multiple mes- 
sage parts. 

In step 705, the client searches a message group ID field 
in the database for each message entry. Next, the client 
identifies all of the message entries having the same message 
group ID, in step 710. Once all of the message entries have 
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been identified, in step 715, the client selects from a local 
message store each message part that corresponds to the 
identified message entries. In step 720, the message parts are 
assembled in numerical order based on a pre -assigned 

5 message part number associated with each message part. 
Next, the message parts are displayed as a single, reas- 
sembled message, in step 725. The process terminates at the 
END step 730. 
The process of FIG. 8 may be illustrated by way of the 

10 following example with continuing reference to FIG. 4. In 
this example, the user desires to retrieve a message having 
multiple parts. Referring to FIG. 4/, the message entries 
having UIDLs"ijkl" and "mnop" are indicative of a message 
having multiple parts. As shown in FIG. 4i, the message 

15 group ID for these message entries is "zcy**. 

The message manager program module 37 searches the 
message group ID field 240 in the database 39 and identifies 
session IDs "2" and "3" as having the same message group 
ID "zcy**. The exemplary program module 37 then selects 
from the local message store 38 located at the client 20 the 
message parts corresponding to the message group ID based 
on the total parts number. The message manager program 
module 37 then assembles the message parts in accordance 
with the number provided in the message parts number field 
245 located in the database 39 to produce a single message. 
In this case, the messages corresponding to UIDLs "ijkl" and 
"mnop" are assembled in the order "ijklmnop" to from a 
single message. 

Message reassembly occurs preferably after communica- 
tion is disconnected between the client and the server. 
Reassembling a message at this time eliminates unnecessary 
consumption of time during a client-server session. 
Advantageously, accessing these data fields in a database on 

2j the client is a more efficient and timely operation than 
retrieving the necessary message assembly information from 
the local message stole. 

The present invention provides a system for managing 
messages communicated within a client-server architecture 

40 such as a distributed computing environment represented by 
a client and a server. The present invention, namely a 
message manager program module, uses a database, stored 
at the client, to maintain a central archive of message-related 
information to support current and future message commu- 

45 nication operations between the client and the server. Com- 
munications with a message server are facilitated by access- 
ing a client-based database representing a central archive of 
message -related information. Archived information is 
accessed in the client-based database during typical message 

50 communications operations, such as message download and 
delete operations. The client-based database is also used to 
Support efficient management of messages having multiple 
message parts, i.e., message re-assembly. 

The invention may conveniently be implemented in one 

55 or more program modules that are based upon and imple- 
ment the features illustrated in FIGS. 3-8, No particular 
programming language has been described for carrying out 
the various procedures described above because it is con- 
sidered that the operations, steps, and procedures described 

60 above and illustrated in the accompanying drawings are 
sufficiently disclosed to permit one of ordinary skill in the art 
to practice the present invention. Moreover, there are many 
computers and operating systems which may be used in 
practicing the present invention and therefore no detailed 

65 computer program could be provided which would be appli- 
cable to all of these many different systems. Each user of a 
particular computer will be aware of the language and tools 
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which are most useful for that user*s needs and purposes. In 
addition, although the invention was described in the context 
of a e-mail client, mail server, and message store, that 
implement one of a variety of Internet protocols, those 
skilled in the art will appreciate that the invention is appli- 
cable to remote servers that include other types of data 
stores, message stores, and file stores, and in other operating 
environments. 

Alternative embodiments will become apparent to those 
skilled in the art to which the present invention pertains 
without departing from its spirit and scope. Accordingly, the 
scope of the present invention is defined by the appended 
claims rather than the foregoing description. 

What is claimed is: 

1. In a distributed computer system including a server and 
a client, the client including a local message store and a 
client-based database, a method for managing electronic 
mail messages based on message-related information corre- 
sponding to each message stored in the client-based 
database, comprising the steps of: 

(A) during a client-server session, retrieving from the 
server the message-related information corresponding 
to a message; 

(B) based on the message-related information, determin- 
ing whether the message has been downloaded from the 
server to the local message store located at the client; 

(C) in response to determining that the message has not 
been downloaded from the server to the local message 
store, 

i. downloading the message from the server to the local 
message store, 

ii. populating data fields in the client-based database 
with the message-related information, 

iii. providing an indication in the client-based database 
that the message is present on the server, and 

iv. providing an indication in the client-based database 
that the message has been downloaded from the 
server to the local message store; 

(D) repeating the steps (A) through (C) for each remain- 
ing message on the server; and 

(E) consulting the client-based database for managing the 
messages during subsequent client-server sessions. 

2. The method of claim 1, wherein the step of download- 
ing the message from the server to the local message store 
comprises: 

determining whether a size restriction has been set for 
downloading the message; 

in response to determining that a size restriction has been 
set for downloading the message, determining whether 
a message size for the message is greater than a 
predetermined size limit; and 

in response to determining that either 1) a size restriction 
has not been set for downloading the message or 2) the 
message size for the message is not greater than the 
predetermined size limit, downloading the message 
from the server to the local message store, 

3. The method of claim 1, further comprising the step of: 
in response to determining that the message has been 

downloaded from the server to the local message store, 
identifying in the client-based database the message- 
related information corresponding to the message and 
providing an indication in the client-based database that 
the message is present on the server. 

4. The method of claim 1, further comprising the steps of: 
determining whether the client is in a "leave on server" 

mode, the "leave on server" mode indicating that the 
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message remains on the server after the message has 
been downloaded from the server to the local message 
store; and 

in response to determining that the client is not in the 
"leave on server" mode, providing an indication in the 
client-based database to delete the message and based 
on the provided indication, deleting the message- 
related information for the message from the client- 
based database and the message from the server. 

5. The method of claim 4, further comprising the steps of: 
in response to determining that the client is in the "leave 

on server" mode, determining whether a lime expira- 
tion has been set for deleting the message; 
in response to determining that a time expiration has been 
set for deleting the message, 

i. determining whether the time has expired for the 
message, and 

ii. in response to determining that the time has expired 
for the message, providing an indication in the 
cUent-based database to delete the message and 
based on the provided indication, deleting the 
message -related information for the message from 
the client-based database and the message from the 
server. 

6. The method of claim 5, wherein the step of determining 
whether the time has expired for the message comprises 
comparing a date and time for the message to a preset period 
of time allowed for the message-related information to 
remain in the client-based database. 

7. The method of claim 5, further comprising the steps of: 
in response to determining that a time expiration has not 

been set for deleting the message, determining whether 
an indication to delete the message has been provided 
in the client-based database; and 
in response to determining that an indication to delete the 
message has been provided in the client-based 
database, deleting the message-related information for 
the message from the client-based database and the 
message from the server. 

8. The method of claim 5, wherein the step of providing 
an indication to delete the message comprises setting a 
"delete" flag in the client-based database. 

9. The method of claim 1, wherein the message-related 
information comprises a unique identifier for identifyling the 
message and a session identifier for indicating the order in 
which the message is downloaded from the server to the 
client. 

10. The method of claim 9, wherein the message-related 
information further comprises a message size and a date and 
time. 

11. The method of claim 9, wherein the data fields 
comprise a unique identification field for storing the unique 
identifier, a session identification field for storing the session 
identifier, a message size field for storing the message size, 
and a date and time field for storing the date and time. 

12. The method of claim 11, wherein the step of popu- 
lating the data fields in the cHent-based database with the 
message-related information further comprises the steps of: 

populating the unique identification field with the unique 
identifier; 

populating the session identification field with the session 
identifier; 

populating the message size field with the message size; 
and 

populating the date and lime field with the date and time. 

13. The method of claim 1, wherein the step of providing 
an indication in the client-based database that the message is 
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present on the server comprises setting an "on server" flag 
to a true state in the client-based database. 

14. The method of claim 13, further comprising the steps 

of: 

clearing a session identifier before each subsequent client- 
server session; and 

changing the "on server" flag from the true state to an 
unknown state before each subsequent client-server 
session, the unknown state indicating that the state of 
the message being present on the server is unknown. 

15. The method of claim 14, further comprising the steps 

of: 

during each subsequent client-server session, changing 
the "on server" flag from the unknown state to a false 
slate when the message associated with the message- 
related information is not present on the server; 

providing an indication in the client-based database to 
delete the message; and 

based on the provided indication, deleting the message- 
related information for the message from the client- 
based database after each subsequent client-server ses- 
sion has discontinued. 

16. The method of claim 1, wherein the step of providing 
an indication in the client-based database that the message 
has been downloaded comprises setting a "download" flag in 
the client-based database. 

17. In a distributed computer system including a server 
and a client including a locaLmessage store and a client- 
based database, a method for removing from the client-based 
database message entries for electronic mail messages based 
on message-related information corresponding to each mes- 
sage stored in the client-based database, comprising the 
steps of: 

(A) consulting the client-based database comprising at 
least one message entry containing message-related 
information corresponding to one of a selected mes- 
sage; 

(B) determining whether the client is in a "leave on 
server'* mode, the "leave on server** mode indicating 
that the selected message remains on the server after 
the selected message has been downloaded from the 
server to the local message store located at the client; 

(C) in response to determining that the client is not in the 
"leave on server*' mode, providing an indication in the 
corresponding message entry in the client-based data- 
base to remove the selected message; 

(D) in response to determining that the client is in the 
"leave on server" mode, determining whether a time 
expiration has been set for removing the selected 
message; 

(E) in response to determining that a time expiration has 
been set for removing the selected message, 

i. determining whether the time has expired for the 
selected message, and 

ii. in response to determining that the time has expired 
for the selected message, providing the indication in 
the corresponding message entry in the client-based 
database to remove the selected message; and 

(F) in response to providing the indication in the corre- 
sponding message entry to remove the selected 
message, removing the corresponding message entry 
for the selected message from the client-based database 
and the selected message from the server. 

18. The method of claim 17, further comprising the step 

of: 
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(G) repeating steps (B) through (F) for each remaining 
message on the server. 

19. The method of claim 17, wherein the step of deter- 
mining whether the time has expired for the selected mes- 

5 sage comprises comparing a date and lime for the selected 
message to a preset period of lime allowed for the corre- 
sponding message entry to remain in the client-based data- 
base. 

20. The method of claim 17, wherein the step of providing 
an indication to remove the selected message comprises' 
selling a "delete*' flag in the corresponding message entry in 
the client-based database. ^ 

21. The method of claim 17, wherein the time expiration 
J J is set based on user-provided input. 

22. The method of claim 17, fiirther comprising the steps 
of: 

providing a user-prompted indication in the correspond- 
ing message entry in the client-based database to 
20 remove the selected message, where the user-prompted' 
indication is not based on the time expiration or the 
server mode; and 
based on the user-prompted indication, removing the 
corresponding message entry from the client-based 
25 database and the selected message from the server. 

23. The method of claim 17, further comprising the step 
of removing from the client-based database each message 
entry that does not have an associated message on the server. 

24. In a distributed computer system including a server 
30 and a client including a local message store and a client- 
based database, a method for obtaining selected messages 
based on message-related information stored in the client- 
based database, comprising the steps of: 

A) storing in the client-based database at least one mes- 
35 sage entry having a unique identifier, each message 

entry corresponding to one of the selected messages 
and containing message-related information for the 
message; 

B) retrieving from the server: 

i. a session identifier corresponding to the selected 
message, the session identifier indicating the order in 
which the selected message is downloaded from the 
server to the local message store located at the client, 
and 

ii. a tmique identifier corresponding to the message, the 
unique identifier identifying the message; 

C) determining whether the unique identifier for the 
selected message matches the unique identifier of the 
corresponding message entry; 

D) if the imique identifier for the selected message 
matches the unique identifier of the corresponding 
message entry, then: 

i. appending the session identifier for the selected 
55 message to the corresponding message entry, and 

ii. providing an indication in the client-based database 
that the selected message is present on the server, and 

E) if the unique identifier for the selected message does 
not match the unique identifier of the corresponding 

60 message entry, then: 

i. downloading the selected message from the server to 
the local message store, 

ii. storing the message-related information in the cor- 
responding message entry, the message related infor- 

65 mation including: 

a) the session identifier for the selected message, 

b) the unique identifier for the selected message. 
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c) a message size for the selected message, and 

d) a date and time for the selected message, 

iii. providing an indication in the corresponding mes- 
sage entry that the selected message is present on the 
server, and 

iv. providing an indication in the corresponding mes- 
sage entry that the selected message has been down- 
loaded from the server to the local message store. 

25. The method of claim 24, further comprising the step 
of repeating the steps B) through E) for each remaining 
message on the server. 

26. The method of claim 24, wherein the step of down- 
loading the message from the server to the local message 
store comprises: 

determining whether a size restriction has been set for 
downloading the message; 

in response to determining that a size restriction has been 
set for downloading the message, determining whether 
a message size for the message is greater than a 
predetermined size limit; and 

in response to determining that either 1) a size restriction 20 
has not been set for downloading the message or 2) the 
message size for the message is not greater than the 
predetermined size limit, downloading the message 
from the server to the local message store. 

27. The method of claim 24, wherein the steps D) ii. and 
E) iii. comprise setting an "on server" flag in the client-based 
database to indicate that the selected message is present on 
the server. 

28. The method of claim 24, wherein the step E) iv. 
comprises setting a "download" flag in the client-based 
database to indicate that the selected message has been 
downloaded from the server to the local message store. 

29. The method of claim 24, further comprising the step 
of setting a "delete" flag in the client-based database for the 
corresponding message entry if the time and date for the 
selected message has expired. 35 

30. The method of claim 29, further comprising the step 
of removing the corresponding message entry from the 
client-based database and the selected message from the 
server if a "delete" flag for the corresponding message entry 
has been set in the client-based' database. ^ 

31. A method for assembling a message at a client, the 
message having multiple message parts in a local message 
store located at the client, comprising the steps of: 

(A) in a chent-based database, storing a corresponding 
message entry for each of the message parts of the 
message, each of the corresponding message entries 
including: 

i. a message group identifier for identifying the mes- 
sage parts for the message, 

ii. a message part number for identifying the order of 
each of the message parts for the message, and 

iii. a total parts number for indicating the number of 
message parts in the message; 

(B) identifying in the client-based database each message 
entry having the same message group identifier; 

(C) selecting from the local message store the message 
parts having the same message group identifier based 
on the identified message entries in the client-based 
database; and 

(D) assembling at the client the message parts in order 
based on the message part number for each of the 
corresponding message entries in the client-based 
database, the assembled parts forming the message. 

32. The method of claim 31, wherein the step c) is further 
based on the total parts number for each of the correspond- 
ing message entries in the client-based database, whereby 65 
selection of the message parts fi'om the local message store 

is limited to the total parts number. 
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33. In a client-server environment, a system for managing 
electronic mail during a client-server session, comprising: 

(A) a server comprising a message and associated 
message-related information, the associated message- 
related information including: 

i. a unique identifier for identifying the message, 

ii. a session identifier for indicating the order in which 
the message is downloaded from the server during 
the client-server session, 

iii. a message size, and 

iv. a date and time for the message; and 

(B) a client operative to retrieve the message and the 
associated message -related information from the 
server, the client comprising: 

i. a local message store operative to store the message 
retrieved by the client from the server, and 

ii. a database operative to store the associated message- 
related information retrieved by the client from the 
server, 

iii. the database comprising message entries having a 
plurality of data fields, including: 

a. a unique identification field for storing the unique 
identifier, 

b. a session identification field for storing the session 
identifier, 

c. a message size field for storing the message size, 
and 

d. a date and time field for storing the date and time, 
wherein the data fields of a selected one of the 
message entries are populated with the associated 
message -related information for the message 
downloaded from the server to the local message 
store. 

34. The system of claim 33, wherein the client consults 
the database for managing messages on the server during 
subsequent client -server sessions. 

35. The system of claim 34, wherein the client checks the 
unique identifier for the message in the subsequent client- 
server sessions to determine whether a subsequent message 
associated with the subsequent client -server sessions is to be 
downloaded from the server to the local message store. 

36. The system of claim 33, wherein the message includes 
multiple message parts each message part having a corre- 
sponding message entry such that the database comprising 
the message entries having the plurality of data fields further 
includes: 

a message group field for storing a message group iden- 
tifier for identifying the message parts for the message; 

a message part number field for storing a message part 
number for identifying the order of each of the message 
parts for the message; and 

a total parts field for storing a total parts number for 
indicating the number of message parts in the message. 

37. The system of claim 33, wherein the database com- 
prising the message entries having the plurality of data fields 
further includes: 

a "delete" flag field for setting a delete flag to mark the 
message for deletion from the server and associated 
message-related information for deletion from the data- 
base; 

an "on server" flag field for setting an "on server" flag to 
indicate that the message is present on the server; and 

a "download" flag field for setting a "download flag" to 
indicate that the message has been downloaded from 
the server to the local message store. 
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